GermanWikipedia - /page/entry.mu

Micron Document

<!DOCTYPE html>

<title>Sender Policy Framework</title>

</head>

<h1 id="firstHeading" class="firstHeading mw-first-heading"><span class="mw-page-title-main">Sender Policy Framework</span></h1>

</header>

</div>

<p>Das <b>Sender Policy Framework</b> (<b>SPF</b>; früher <b>Sender Permitted From</b>) ist ein Verfahren, mit dem das Fälschen der Absenderadresse einer <a href="E-Mail" title="E-Mail">E-Mail</a> verhindert werden soll, genauer das Versenden von E-Mail über nicht legitimierte <a href="Mail_Transfer_Agent" title="Mail Transfer Agent">Mail Transfer Agents</a> (MTAs) unterbindet. Es entstand als Verfahren zur Abwehr von <a href="Spam" title="Spam">Spam</a>. Bei SPF trägt der Inhaber einer <a href="Domain_(Internet)" title="Domain (Internet)">Domain</a> in das <a href="Domain_Name_System" title="Domain Name System">Domain Name System</a> ein, welche Adressen von MTAs zum Versand von E-Mails für diese Domain berechtigt sind.

</p>

<div class="mw-heading mw-heading2"><h2 id="Funktionsweise">Funktionsweise</h2></div>

<p>Der Administrator einer <a href="Domain_(Internet)" title="Domain (Internet)">Domain</a> hinterlegt in der <a href="Zone_(DNS)" title="Zone (DNS)">DNS-Zone</a> einen <a href="Resource_Record" title="Resource Record">Resource Record</a> vom Typ <code><a href="TXT_Resource_Record" title="TXT Resource Record">TXT</a></code> (der <a href="SPF_Resource_Record" title="SPF Resource Record">SPF Resource Record</a> wurde durch RFC 7208 obsolet<sup id="cite_ref-1" class="reference"><a href="#cite_note-1"><span class="cite-bracket">[</span>1<span class="cite-bracket">]</span></a></sup>). In diesen Resource Records sind die <a href="IP-Adresse" title="IP-Adresse">IP-Adressen</a> der <a href="Mail_Transfer_Agent" title="Mail Transfer Agent">Mail Transfer Agents</a> (MTA) enthalten, die für die Domain E-Mails versenden dürfen. Der Empfänger prüft, ob der <a href="Absender" title="Absender">Absender</a> zum Versand berechtigt ist. Hierzu schaut sich der Empfänger an, welche Domain der Absender in den Feldern <code><a href="Envelope_Sender" title="Envelope Sender">MAIL FROM</a></code> und <code>HELO</code> in der <a href="Simple_Mail_Transfer_Protocol" title="Simple Mail Transfer Protocol">SMTP-Verbindung</a> angegeben hat. Für die angegebene Domain ruft der Empfänger die SPF-Information über das Domain Name System ab und vergleicht die IP-Adresse des sendenden MTAs mit den erlaubten Adressen. Stimmt die IP-Adresse überein, so ist der Absender authentisch, andernfalls kann die E-Mail verworfen werden.

</p><p>Zu beachten ist, dass diese Überprüfung sich nicht auf die Kopfzeile <code>From</code> bezieht, welche normalerweise von E-Mail-Programmen als Absender angezeigt wird und zusätzlich auch einen Namen enthalten kann. SPF kann somit nicht davor schützen, dass Betrüger versuchen, Verbraucher zu täuschen. Es kann jedoch helfen, diese zu ermitteln.

</p><p>Im DNS-Eintrag einer Domäne sind bislang schon normale <a href="MX_Resource_Record" title="MX Resource Record"><code>MX</code>-Einträge</a> vorhanden, die <a href="Simple_Mail_Transfer_Protocol" title="Simple Mail Transfer Protocol">SMTP</a>-Servern sagen, an welchen Host sie E-Mails für diese Domäne senden sollen. Wenn also ein SMTP-Server eine E-Mail an <code>test@example.org</code> schicken soll, sieht er im <code>MX</code>-Record von <code>example.org</code> nach, an welchen Server er die Mail schicken soll. Mit SPF wird nun ein Record im Stil eines Reverse-MX den DNS-Einträgen einer Domäne hinzugefügt. Empfängt ein Mailserver eine E-Mail mit einem Absender von <code>example.org</code>, sieht er im SPF-Record von <code>example.org</code> nach, ob der zustellende Mailserver laut SPF-Record dazu berechtigt ist, Mails für diese Domain zu versenden.

</p><p>SPF kann so durch die leichtere Nachverfolgbarkeit von E-Mails auch zur Bekämpfung von <a href="Spam" title="Spam">Spam</a> und zur Erschwerung von <a href="Phishing" title="Phishing">Phishing</a> beitragen. SPF erhebt jedoch lediglich den Anspruch, Absenderadressfälschungen zu verhindern, nicht aber, direkt Spam zu bekämpfen.

</p><p>SPF muss nur vom Empfängersystem unterstützt werden – am Protokoll der Mailübertragung (SMTP) ändert sich nichts. Die Veröffentlichung von SPF-Records ist für eine Domäne freiwillig, Mails von Domains ohne SPF-Records sollen laut SPF-Spezifikation (RFC 4408<sup id="cite_ref-RFC4408_2-0" class="reference"><a href="#cite_note-RFC4408-2"><span class="cite-bracket">[</span>2<span class="cite-bracket">]</span></a></sup>) von Empfängern nicht negativ eingestuft werden; allerdings bleiben solche Domänen naturgemäß wie bisher gegen Umschlag-Adressfälschungen ungeschützt.

</p>

<div class="mw-heading mw-heading2"><h2 id="Aufbau_eines_SPF-Records">Aufbau eines SPF-Records</h2></div>

<p>Jeder SPF-Record beginnt mit einer Versionsnummer – für die aktuelle SPF-Version <code>v=spf1</code>. Es folgen beliebig viele Ausdrücke, die in der Reihenfolge von vorne nach hinten ausgewertet werden. Die meisten Ausdrücke sind dabei <i>Direktiven</i>, die die <a href="Autorisierung" title="Autorisierung">Autorisierung</a> des Versenders definieren, und bestehen aus einem optionalen Qualifikator und einem <i>Mechanismus</i>, der für eine gegebene Situation (IP-Adresse) entweder einen Treffer oder keinen Treffer ergibt. Der erste Mechanismus, der einen Treffer darstellt, bestimmt das Ergebnis der gesamten Auswertung des SPF-Records.

</p><p>Es gibt folgende Qualifikatoren:

</p>

<th>Ergebnis-Code</th>

<th>Beschreibung

</th></tr>

<tr>

<td>die Direktive definiert autorisierte Sender;<br> dies ist der Standard, d. h. ist kein Qualifikator angegeben, so wird <code>+</code> angenommen

</td></tr>

<tr>

<td>die Direktive definiert nicht autorisierte Sender

</td></tr>

<tr>

<td><code>Softfail</code></td>

<td>die Direktive definiert nicht autorisierte Sender, der Empfänger soll diesen Fehlschlag aber großzügig behandeln.

</td></tr>

<tr>

<td><code>Neutral</code></td>

<td>die Direktive definiert Sender, über deren Legitimität nichts ausgesagt werden soll; der Sender muss so behandelt werden, als wenn kein Qualifikator angegeben wäre.

</td></tr></tbody></table>

<p>Folgende Tabelle zeigt einige gängige Mechanismen:

</p>

<th>Direktive trifft zu, wenn …

</th></tr>

<tr>

<td>immer

</td></tr>

<tr>

<td>… ein <code>A</code>- oder <code>AAAA</code>-Record der befragten (oder explizit angegebenen) Domäne die IP-Adresse des Senders enthält

</td></tr>

<tr>

<td>… ein <code>MX</code>-Record der befragten (oder explizit angegebenen) Domäne die IP-Adresse des Senders enthält

</td></tr>

<tr>

<td>… die angegebene IPv4-Adresse die IP-Adresse des Senders ist bzw. das angegebene IPv4-Subnetz diese enthält

</td></tr>

<tr>

<td>… die angegebene IPv6-Adresse die IP-Adresse des Senders ist bzw. das angegebene IPv6-Subnetz diese enthält

</td></tr>

<tr>

<td><code>include</code></td>

<td>… eine zusätzliche SPF-Anfrage zur im Include-Statement angegebenen Domain die IP-Adresse des Senders enthält

</td></tr></tbody></table>

<p>Einen Überblick über alle erlaubten Ausdrücke gibt die Unterseite der SPF-Website.<sup id="cite_ref-syntax_3-0" class="reference"><a href="#cite_note-syntax-3"><span class="cite-bracket">[</span>3<span class="cite-bracket">]</span></a></sup>

</p><p>Neben den Direktiven gibt es Attribute (<i>Modifier</i>), die nur einmalig vorkommen können und zusätzliche Informationen bereitstellen:

</p>

<th>Modifier</th>

<th>Beschreibung

</th></tr>

<tr>

<td><code>redirect</code></td>

<td>Der SPF-Record einer anderen Domain soll eingeholt und ausgewertet werden

</td></tr>

<tr>

<td>Verweist auf eine Domain, deren TXT-Record eine Erklärung für den Nutzer enthält, falls die E-Mail abgewiesen wurde

</td></tr></tbody></table>

<div class="mw-heading mw-heading2"><h2 id="Beispiel">Beispiel</h2></div>

<pre>$ host -t TXT gmx.de

gmx.de descriptive text "v=spf1 ip4:213.165.64.0/23 ip4:74.208.5.64/26 ip4:212.227.126.128/25 ip4:212.227.15.0/25 ip4:212.227.17.0/27 ip4:74.208.4.192/26 ip4:82.165.159.0/24 ip4:217.72.207.0/27 -all"

</pre>

<p>Die Firma <a href="Global_Message_Exchange" class="mw-redirect" title="Global Message Exchange">GMX</a> legt also fest, dass alle Hosts mit der IPv4-Adresse 213.165.64.0 bis 213.165.65.255, sowie 74.208.5.64 bis 74.208.5.127 und einige weitere Adressbereiche E-Mails von der Domäne <code>gmx.de</code> verschicken dürfen. Alle anderen Server sind laut diesem SPF-Record nicht für die Benutzung dieser Domäne in der Umschlag-Absenderadresse autorisiert.

</p>

<div class="mw-heading mw-heading2"><h2 id="Status">Status</h2></div>

<p>SPF besteht in der Version 1 schon seit Ende 2003 größtenteils unverändert, zu Beginn als informelle Spezifikation. Am 28. April 2006 wurde SPFv1 von der <a href="Internet_Engineering_Task_Force" title="Internet Engineering Task Force">IETF</a> als RFC 4408<sup id="cite_ref-RFC4408_2-1" class="reference"><a href="#cite_note-RFC4408-2"><span class="cite-bracket">[</span>2<span class="cite-bracket">]</span></a></sup> veröffentlicht. Das <a href="Request_for_Comments" title="Request for Comments">RFC</a> hat den Status „Experimental“, da die im Vorlauf eingestellte IETF-Arbeitsgruppe „marid“ (<i>MTA Authorization Records in DNS</i>) mehrere zur Debatte stehende Verfahren bearbeitete, sich jedoch nicht auf eines der Verfahren einigen konnte. Im April 2014 veröffentlichte die IETF den RFC 7208 <i>Sender Policy Framework (SPF)</i><sup id="cite_ref-4" class="reference"><a href="#cite_note-4"><span class="cite-bracket">[</span>4<span class="cite-bracket">]</span></a></sup> als „Proposed Standard“, welcher im September 2014 durch den von der IETF-Arbeitsgruppe „spfbis“ veröffentlichten RFC 7372<sup id="cite_ref-5" class="reference"><a href="#cite_note-5"><span class="cite-bracket">[</span>5<span class="cite-bracket">]</span></a></sup> (ebenfalls als „Proposed Standard“) ergänzt wurde.

</p><p>Zu den bekanntesten Unterstützern von SPF unter den E-Mail-Dienstleistern gehören unter anderem (Stand 2020):

</p>

<th>E-Mail-Dienstleister</th>

<th>Qualifikator

</th></tr>

<tr>

<td><a href="Arcor" title="Arcor">Arcor</a>/Vodafone</td>

<td>Softfail

</td></tr>

<tr>

<td>Fail

</td></tr>

<tr>

<td>Fail

</td></tr>

<tr>

<td>Softfail

</td></tr>

<tr>

<td><a href="Gmail" title="Gmail">Gmail</a></td>

<td>Softfail

</td></tr>

<tr>

<td>Softfail

</td></tr>

<tr>

<td><a href="Microsoft" title="Microsoft">Microsoft</a> (<a href="Hotmail" title="Hotmail">Hotmail</a> und <a href="Outlook.com" title="Outlook.com">Outlook.com</a>)</td>

<td>Softfail

</td></tr>

<tr>

<td><a href="Yahoo_Mail" title="Yahoo Mail">Yahoo</a></td>

<td>Neutral

</td></tr></tbody></table>

<p>GMX setzt SPF bereits seit April 2004 produktiv ein.

</p><p>SPF ist nicht nur für E-Mail-Dienstleister interessant, sondern auch allgemein für Unternehmen, die E-Mails an ihre Kunden versenden und mit SPF den Empfängern die Möglichkeit bieten, E-Mails, die von nicht vom Unternehmen autorisierten IP-Adressen, jedoch mit der Absender-Domäne des Unternehmens versendet wurden, entsprechend dem vom Unternehmen vorgegebenen Qualifikator zu behandeln.

Die Top-10-Websites in Deutschland<sup id="cite_ref-6" class="reference"><a href="#cite_note-6"><span class="cite-bracket">[</span>6<span class="cite-bracket">]</span></a></sup> nutzen alle SPF (Stand 2020):

</p><p><a href="Spamfilter" title="Spamfilter">Spamfilter</a> wie beispielsweise <a href="SpamAssassin" title="SpamAssassin">SpamAssassin</a> nutzen SPF-Verifizierung zur Bewertung eingehender E-Mails. In der Standardkonfiguration von SpamAssassin hat eine erfolgreiche SPF-Prüfung jedoch keinen Effekt, da dies laut Aussage der Entwickler von Spam-Versendern ausgenutzt würde.<sup id="cite_ref-7" class="reference"><a href="#cite_note-7"><span class="cite-bracket">[</span>7<span class="cite-bracket">]</span></a></sup> Zum Teil fließt eine fehlgeschlagene Prüfung in die Bewertung ein, je nach Fehlergrund.

</p><p>Viele Mail-Betreiber informieren über eine erfolgte SPF-Verifikation im <a href="Header_(E-Mail)" title="Header (E-Mail)">Mailheader</a>, zum Beispiel durch das Einfügen einer Zeile

</p>

<pre>Received-SPF: pass (gmail.com: domain of foo@example.org designates 127.0.0.1 as permitted sender)

</pre>

<p>oder

</p>

<pre>X-Warning: SPF records of example.org exclude 127.0.0.2

</pre>

<div class="mw-heading mw-heading2"><h2 id="Probleme_bei_Mail-Umleitung">Probleme bei Mail-Umleitung</h2></div>

<p>Der Einsatz von SPF kann Probleme verursachen, wenn der Empfänger seine E-Mails an ein Postfach unterhalb einer anderen Domäne umleiten lässt: Das empfangende System sieht in diesem Fall die Domain des Absenders in Verbindung mit der IP-Adresse des umleitenden Systems. Letzteres wird jedoch typischerweise nicht von den SPF-Regeln erfasst sein, sodass eine solche Mail bei einer SPF-Prüfung als unautorisiert eingestuft wird.

</p><p>Zu diesem Problem existieren drei Lösungsansätze:

</p>

<ol><li>Das empfangende System verzichtet auf die SPF-Prüfung von Mails der umleitenden Domains, sofern sie ihm bekannt sind – beispielsweise durch ein <a href="Wei%C3%9Fe_Liste" title="Weiße Liste">Whitelisting</a>. Sinnvollerweise sollten in diesem Fall die weiterleitenden Systeme die SPF-Prüfung übernehmen. Ein Nachteil dieses Verfahrens ist, dass im Falle eines Zustellungsfehlers die Fehlermeldung (Bounce) direkt an den Absender gesandt wird. Dieser könnte so von der Zieladresse der Umleitung erfahren, was u. U. vom Empfänger unerwünscht ist.</li>

<li>Dieses Problem wird vermieden, wenn das Weiterleitungssystem die Umschlag-Absenderadressen der umgeleiteten Mails auf seine eigene Domäne umschreibt und so die Verantwortung für die Gültigkeit der ursprünglichen Absenderadresse und für die Zustellung eventueller <a href="Bounce_Message" title="Bounce Message">Bounces</a> übernimmt. Ein solches Verfahren ist z. B. das <a href="Sender_Rewriting_Scheme" title="Sender Rewriting Scheme">Sender Rewriting Scheme</a> (SRS). Es muss allerdings sichergestellt sein, dass das weiterleitende System eine wirksame SPF-Prüfung vornimmt, was z. Zt. nicht immer der Fall ist.</li>

<li>Der sendende Server sendet die Daten erst an den erlaubten Mailserver weiter (relaying). Im Internet kann man hierzu sog. Satelliten-Mailserver nutzen, welche dann autorisiert sind, Daten vom Webserver zu empfangen und diese an den eigenen Mailserver weiterzuleiten.</li></ol>

<div class="mw-heading mw-heading2"><h2 id="Implementierung_von_Webformularen">Implementierung von Webformularen</h2></div>

<p>SPF kann bei Webformularen, die eine E-Mail mit fremder Absenderadresse erzeugen, zu Zustellungsproblemen führen. So gibt es Webformulare, die den Namen und die E-Mail-Adresse abfragen. Wenn das Webformular nun dem Webseitenbetreiber per Mail zugestellt wird, kann die Absenderadresse frei gewählt werden. Falls das Webformular die Absenderadresse aus dem Formular übernimmt, wirkt die Mail so, als käme sie direkt von der Person, die die Daten ausgefüllt hat. Wenn diese Domain jedoch SPF eingerichtet hat und der Mailserver des Webseitenbetreibers selbst SPF-Prüfungen durchführt, handelt es sich um einen SPF-Verstoß. Dadurch wird das abgeschickte Formular möglicherweise nie beim Webseitenbetreiber eingehen.

</p><p>Dieses Problem lässt sich vermeiden, wenn sich der Webserver selbst als Absender der Mail identifiziert und seine eigene, berechtige Domain als <a href="Envelope_Sender" title="Envelope Sender">Envelope Sender</a> für die E-Mail nutzt. Die E-Mail-Adresse aus dem Formular kann entweder im Text der Mail, im <a href="Header_(E-Mail)#From:_Absender" title="Header (E-Mail)">From</a>-Header oder <a href="Reply-To" class="mw-redirect" title="Reply-To">Reply-To</a>-Header hinterlegt werden. Der From-Header wird in <a href="E-Mail-Programm" title="E-Mail-Programm">E-Mail-Programmen</a> als Absenderadresse angezeigt, an den unmittelbar geantwortet werden kann, ist jedoch kein Bestandteil der SPF-Prüfung. In Kombination mit dem neueren <a href="DMARC" title="DMARC">DMARC</a>-Verfahren würde dies jedoch fehlschlagen, da der From-Header einer Prüfung unterliegt. Das Problem besteht nicht bei Verwendung des Reply-To-Headers, da dieser keiner Absenderprüfung unterliegt. Gängige E-Mail-Programme unterstützen die direkte Antwort an die Reply-To-Adresse.

</p>

<div class="mw-heading mw-heading2"><h2 id="Kritik">Kritik</h2></div>

<p>Im Bereich der Nutzung von nicht autorisierten Mail Transfer Agents (MTAs) für die mit SPF geschützte Domain ist SPF ein kontrovers diskutiertes Verfahren.

</p>

<ul><li>Endbenutzer haben im Allgemeinen keine Kenntnis von der Existenz von SPF und der Notwendigkeit, bei Umleitung Whitelisting einzuschalten. Bei der Einrichtung einer E-Mail-Umleitung an einem System, welches unzureichend ohne <a href="Sender_Rewriting_Scheme" title="Sender Rewriting Scheme">Sender Rewriting Scheme</a> (SRS) arbeitet, bekommen Benutzer keine E-Mails aus SPF-geschützten Domains mehr zugestellt.</li>

<li>Durch die Einschränkung der erlaubten <a href="Mail_Transfer_Agent" title="Mail Transfer Agent">MTA-Adressen</a> einer Domain werden auch verschiedene Nutzungsszenarien eingeschränkt, welche üblicherweise im Bereich des Spam-Versand angewendet und daher unterbunden werden. Im lokalen Netz des Arbeitgebers, der Universität und dergleichen können ausgehende SMTP-Verbindungen durch die <a href="Firewall" title="Firewall">Firewall</a> unterbunden werden. Das geschieht, um Spamversand aus dem Netz heraus einzuschränken oder den ausgehenden E-Mail-Verkehr kontrollieren zu können. Möchte ein Benutzer in diesem Netz seine private E-Mail-Adresse verwenden, so kann er keine SMTP-Verbindung zum berechtigten MTA seines privaten E-Mail-Dienstes aufbauen. Setzt der private E-Mail-Provider SPF ein und setzt der Benutzer den nicht berechtigten MTA des lokalen Netzbetreibers wie etwa den des Arbeitgebers ein, entspricht dieses Verhalten der Methode, welche Spammer verwenden, um über offene Mail-Relays Spam-Nachrichten zu versenden. Eine mögliche Lösung ist die Verwendung eines <a href="Mail_Submission_Agent" title="Mail Submission Agent">Mail Submission Agents</a>, dessen Port nicht von der lokalen Firewall blockiert wird, oder ein entsprechender anderer Zugang zum berechtigten MTA.</li>

<li>SPF wirkt nur indirekt gegen <a href="Spam" title="Spam">Spam</a> sowie <a href="Schadprogramm" title="Schadprogramm">Malware</a>, da Spammer „Wegwerfdomains“ und die E-Mail-Systeme gekaperter <a href="Zombie_(Internet)" title="Zombie (Internet)">„Zombie-Computer“</a> mit deren korrekten SPF-Records verwenden. SPF ist auch kein Adressschutz, sondern vielmehr ein Schutz des Domaininhabers, dass für das Versenden von E-Mails mit seiner Domainabsenderadresse nur die für diese Domain berechtigten MTAs verwendet werden, also eine Art Schutz vor der Verwendung von für die betreffende Domain unberechtigten <a href="SMTP-Relay-Server" title="SMTP-Relay-Server">SMTP-Relays</a>.</li></ul>

<div class="mw-heading mw-heading2"><h2 id="Rechtliche_Situation">Rechtliche Situation</h2></div>

<p>Das OLG Karlsruhe urteilte, dass für Teilnehmer am geschäftlichen E-Mail-Verkehr keine berechtigte Sicherheitserwartung bestehe, dass SPF zum Einsatz kommt. Das Fehlen eines SPF-Eintrags stellt nach Auffassung des Gerichts keinen Anscheinsbeweis für fehlende IT-Sicherheitsmaßnahmen dar.<sup id="cite_ref-8" class="reference"><a href="#cite_note-8"><span class="cite-bracket">[</span>8<span class="cite-bracket">]</span></a></sup>

</p>

<div class="mw-heading mw-heading2"><h2 id="Weitere_Verfahren">Weitere Verfahren</h2></div>

<p>Ein anderes Verfahren zur Authentisierung einer E-Mail-Domain und zum Schutz vor <a href="E-Mail-Spoofing" title="E-Mail-Spoofing">E-Mail-Spoofing</a> ist <a href="DomainKeys_Identified_Mail" title="DomainKeys Identified Mail">DomainKeys Identified Mail</a> (DKIM). Im Gegensatz zu SPF arbeitet DKIM mit kryptografischen Signaturen.

</p><p>Das <a href="DMARC" title="DMARC">DMARC</a>-Verfahren setzt auf SPF und DKIM auf und ergänzt eine verbindliche Sender-Policy zum Umgang mit E-Mails, die nicht authentisch sind.

</p>

<div class="mw-heading mw-heading2"><h2 id="Weblinks">Weblinks</h2></div>

<ul><li><a rel="nofollow" class="external text" href="https://kitterman.com/spf/validate.html">SPF-Einträge überprüfen.</a> kitterman.com (englisch)</li>

<li><a rel="nofollow" class="external text" href="https://www.spf-record.de/">SPF-Generator</a> und deutsche Referenzseite zu SPF-Informationen</li>

/* start https://de.wikipedia.org/ */

.mw-parser-output .dewiki-iconexternal>a{background-position:center right!important;background-repeat:no-repeat!important}body.skin-minerva .mw-parser-output .dewiki-iconexternal>a{background-image:url("./_mw_/OOjs_UI_icon_external-link-ltr-progressive.svg")!important;background-size:10px!important;padding-right:13px!important}body.skin-timeless .mw-parser-output .dewiki-iconexternal>a,body.skin-monobook .mw-parser-output .dewiki-iconexternal>a{background-image:url("./_mw_/MediaWiki_external_link_icon.svg")!important;padding-right:13px!important}body.skin-vector .mw-parser-output .dewiki-iconexternal>a{background-image:url("./_mw_/Link.ernal-small-ltr-progressive.svg")!important;background-size:0.857em!important;padding-right:1em!important}

/* end https://de.wikipedia.org/ */

</style><span class="dewiki-iconexternal"><a href="https://datatracker.ietf.org/doc/html/rfc4408" class="extiw external" title="rfc:4408">4408</a></span></i> – <i><span lang="en">Sender Policy Framework, Version 1</span></i>. (englisch).</li>

<li><a rel="nofollow" class="external text" href="https://easydmarc.com/spf-record-check-tools">SPF Record Check and Lookup tool.</a> easydmarc.com</li></ul>

<div class="mw-heading mw-heading3"><h3 id="Kritik_2">Kritik</h3></div>

<ul><li><a rel="nofollow" class="external text" href="http://bradknowles.typepad.com/considered_harmful/2004/05/spf.html">SPF considered harmful.</a> bradknowles.typepad.com (englisch).</li>

<li><a rel="nofollow" class="external text" href="https://www.taugh.com/mp/lmap.html">Problems with Designated Sender.</a> taugh.com (englisch).</li></ul>

<div class="mw-heading mw-heading2"><h2 id="Einzelnachweise">Einzelnachweise</h2></div>

<li id="cite_note-1"><span class="mw-cite-backlink"><a href="#cite_ref-1">↑</a></span> <span class="reference-text"><i><a href="Request_for_Comments" title="Request for Comments">RFC</a>: <span class="dewiki-iconexternal"><a href="https://datatracker.ietf.org/doc/html/rfc7208#section-3.1" class="extiw external" title="rfc:7208">7208</a></span></i> – <i><span lang="en">Sender Policy Framework (SPF)</span></i>. Abschnitt 3.1 (englisch).</span>

</li>

<i><a href="Request_for_Comments" title="Request for Comments">RFC</a>: <span class="dewiki-iconexternal"><a href="https://datatracker.ietf.org/doc/html/rfc4408" class="extiw external" title="rfc:4408">4408</a></span></i> – <i><span lang="en">Sender Policy Framework, Version 1</span></i>. (englisch).</span>

</li>

<a rel="nofollow" class="external text" href="http://www.open-spf.org/SPF_Record_Syntax"><i>SPF Record Syntax</i>.</a></span>

</li>

<li id="cite_note-4"><span class="mw-cite-backlink"><a href="#cite_ref-4">↑</a></span> <span class="reference-text"><i><a href="Request_for_Comments" title="Request for Comments">RFC</a>: <span class="dewiki-iconexternal"><a href="https://datatracker.ietf.org/doc/html/rfc7208" class="extiw external" title="rfc:7208">7208</a></span></i> – <i><span lang="en">Sender Policy Framework (SPF)</span></i>. (englisch).</span>

</li>

<li id="cite_note-5"><span class="mw-cite-backlink"><a href="#cite_ref-5">↑</a></span> <span class="reference-text"><i><a href="Request_for_Comments" title="Request for Comments">RFC</a>: <span class="dewiki-iconexternal"><a href="https://datatracker.ietf.org/doc/html/rfc7372" class="extiw external" title="rfc:7372">7372</a></span></i> – <i><span lang="en">Email Authentication Status Codes</span></i>. September 2014 (englisch).</span>

</li>

<li id="cite_note-6"><span class="mw-cite-backlink"><a href="#cite_ref-6">↑</a></span> <span class="reference-text"><span class="cite"><a rel="nofollow" class="external text" href="https://web.archive.org/web/20200706100959/https://www.alexa.com/topsites/countries/DE"><i>Alexa.</i></a> Top Sites in Germany. Archiviert vom <span class="dewiki-iconexternal"><a class="external text" href="https://redirecter.toolforge.org/?url=https%3A%2F%2Fwww.alexa.com%2Ftopsites%2Fcountries%2FDE">Original</a></span> am <span style="white-space:nowrap;">6. Juli 2020</span><span>;</span><span class="Abrufdatum"> abgerufen am 7. Juli 2020</span> (englisch).</span><span style="display: none;" class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Adc&rfr_id=info%3Asid%2Fde.wikipedia.org%3ASender+Policy+Framework&rft.title=Alexa&rft.description=Alexa&rft.identifier=https%3A%2F%2Fweb.archive.org%2Fweb%2F20200706100959%2Fhttps%3A%2F%2Fwww.alexa.com%2Ftopsites%2Fcountries%2FDE&rft.source=https://www.alexa.com/topsites/countries/DE&rft.language=en"> </span></span>

</li>

<li id="cite_note-7"><span class="mw-cite-backlink"><a href="#cite_ref-7">↑</a></span> <span class="reference-text"><span class="cite"><a rel="nofollow" class="external text" href="https://svn.apache.org/repos/asf/spamassassin/trunk/rules/50_scores.cf"><i>50_score.cf.</i></a> In: <i>apache.org.</i> 2021,<span class="Abrufdatum"> abgerufen am 17. Mai 2023</span> (englisch).</span><span style="display: none;" class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Adc&rfr_id=info%3Asid%2Fde.wikipedia.org%3ASender+Policy+Framework&rft.title=50_score.cf&rft.description=50_score.cf&rft.identifier=https%3A%2F%2Fsvn.apache.org%2Frepos%2Fasf%2Fspamassassin%2Ftrunk%2Frules%2F50_scores.cf&rft.date=2021&rft.language=En"> </span></span>

</li>

<li id="cite_note-8"><span class="mw-cite-backlink"><a href="#cite_ref-8">↑</a></span> <span class="reference-text">Urt. v. 27.07.2023 – 19 U 83/22 [= MMR 2023, 761] Rn. 27. Dazu kritisch: Sebastian Hofmann: <cite style="font-style:italic">IT-Sicherheitsmaßnahmen beim Versand von E-Mails im Geschäftsverkehr: Argumente für einen Anscheinsbeweis</cite>. In: <cite style="font-style:italic">Datenschutz und Datensicherheit - DuD</cite>. <span style="white-space:nowrap">Band<span style="display:inline-block;width:.2em"> </span>48</span>, <span style="white-space:nowrap">Nr.<span style="display:inline-block;width:.2em"> </span>5</span>, Mai 2024, <a href="Internationale_Standardnummer_f%C3%BCr_fortlaufende_Sammelwerke" title="Internationale Standardnummer für fortlaufende Sammelwerke">ISSN</a> <span style="white-space:nowrap"><a rel="nofollow" class="external text" href="https://zdb-katalog.de/list.xhtml?t=iss%3D%221614-0702%22&key=cql">1614-0702</a></span>, <span style="white-space:nowrap">S.<span style="display:inline-block;width:.2em"> </span>310–317</span>, <a href="Digital_Object_Identifier" title="Digital Object Identifier">doi</a>:<span class="uri-handle" style="white-space:nowrap"><a rel="nofollow" class="external text" href="https://doi.org/10.1007/s11623-024-1922-1">10.1007/s11623-024-1922-1</a></span> (<a rel="nofollow" class="external text" href="https://link.springer.com/10.1007/s11623-024-1922-1">springer.com</a> [abgerufen am 19. Juli 2024]).<span class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rfr_id=info:sid/de.wikipedia.org:Sender+Policy+Framework&rft.atitle=IT-Sicherheitsma%C3%9Fnahmen+beim+Versand+von+E-Mails+im+Gesch%C3%A4ftsverkehr%3A+Argumente+f%C3%BCr+einen+Anscheinsbeweis&rft.au=Sebastian+Hofmann&rft.date=2024-05&rft.doi=10.1007%2Fs11623-024-1922-1&rft.genre=journal&rft.issn=1614-0702&rft.issue=5&rft.jtitle=Datenschutz+und+Datensicherheit+-+DuD&rft.pages=310-317&rft.volume=48" style="display:none"> </span></span>

</li>

</ol></div><div><div class="zim-footer">

Dieser Artikel wurde von <a class="external text" title="Zuletzt bearbeitet am 2025-07-31" href="https://de.wikipedia.org/wiki/?title=Sender_Policy_Framework&oldid=258446867">Wikipedia</a> herausgegeben. Der Text ist unter <a class="external text" href="https://creativecommons.org/licenses/by-sa/4.0/deed.de">Creative Commons Attribution-Share Alike 4.0</a> verfügbar, sofern nicht anders angegeben. Für die Mediendateien können zusätzliche Bedingungen gelten.

</div>

</div></div>

</div>

</main>

</div>

</body></html>